1. Field of the Invention
This invention relates to a system and method for communicating signals (referred to as "messages") in a device-independent fashion from an input/output (I/O) device to a software application. More specifically, this invention relates to a system and method for receiving messages from an I/O device, interpreting those messages using object-oriented techniques, and sending the interpreted messages to an application object using an I/O device-independent common protocol.
2. Related Art
In recent years, there has been a move toward creating and using computer programs in an "object-oriented" environment. Such an environment utilizes the concept of "objects," which generally represent manipulatable items having specified "methods." A method represents an operation that an object is capable of performing. The binding of methods into an object is known as "encapsulation."
The items which can be represented by objects include common office objects as well as computer peripherals, computer programs, and documents. An example of such an object (hereafter referred to as an "application object") is one representative of a word processing document. Methods which might be encapsulated within this application object include the ability to invoke a word processing program and to read itself into that word processing program upon receiving a specific message from an I/O device (for example, receiving a left button double-click message from a mouse).
Application objects are typically represented to a user via "icons", which are bitmaps displayed on a visual display device. An icon for a word processing document might, for example, appear as a small grey rectangle with the letters WP in it. The appearance of an icon is typically defined by the bitmap.
Typically, an I/O device such as a mouse allows a user to point to an icon by generating and controlling a pointer marker on the visual display device representative of the I/O device's relative position. In other words, when the I/O device is moved in a given direction, the pointer marker will move in the same direction. In this way, the user can then use the I/O device to move that pointer marker to a desired icon on the visual display device.
The ability to move the pointer marker to the various icons on the visual display device allows a user to utilize the methods of the application objects. This is typically done by moving the icons to various locations on the visual display device, or by using an I/O device to send messages to the application object whose representative icon is pointed to directly. In this way, the icons allow a user to visually relate to the manipulation and interaction of application objects within the object-oriented environment.
An example of manipulating the application objects using icons can be described with reference to the word processing document example above. In this example, a user would manipulate an I/O device such that the pointer marker pointed to the icon representing the word processing document application object. The user could then send the application object a message (for example, by depressing the appropriate button on the I/O device), indicating that the application object is to invoke certain of its methods. In the example noted above, those methods include invoking a word processing program, and causing that program to read in the word processing document.
The above example is one possible way that the application objects can be manipulated in an object-oriented environment to utilize the encapsulated methods of the application objects. As indicated above, icons can typically be moved to other portions of the visual display device using an I/O device. For example, where a mouse is used as the I/O device, by using the pointer marker to point to an icon and depressing and holding one of the buttons on the mouse, a user can move the icon to other portions of the visual display device by moving the mouse.
Again using the above-noted word processing document example, the ability to move icons allows a user to move one of the icons (either the word processing program icon or word processing document icon) representative of an application object on top of the other. In typical object-oriented environments, this "object-object" interaction results in the invocation of the word processing program, and causes that program to read in the word processing document. It should be kept in mind that this result is particular to this word processing document example, and that the results of object-object interactions generally will depend upon the application objects that the icons represent.
As indicated above, I/O devices communicate with object-oriented environments by the sending of messages. In the case of a pointer I/O device such as a mouse, each time one of the buttons on the mouse is depressed, a message is sent to the object-oriented environment. Pushing different buttons or combinations of buttons will typically send different messages. Upon receipt of these messages, it is up to the object-oriented environment as to the interpretation of these messages.
As an example of the interpretation of messages from I/O devices, assume for example that an object-oriented environment contains an application object and icon representative of a word processing program. If a pointer device such a mouse is used to point (with its pointer marker) to the word processing program icon, and then the left button of the mouse is clicked twice, this message needs to be interpreted somewhere in the object-oriented environment. Conventionally, the application object (in this case, the word processing program) itself will receive and interpret this message. Thus, the word processing program would "decide" how to interpret the message. In this example, a message that the left button of a mouse has been depressed might indicate to the application object that the word processing program should now be invoked.
If application object designers knew in advance that a finite number of I/O devices were to be used in conjunction with an application object, then that application object could be designed to interpret all the possible messages which could come from any of those I/O devices. For example, the application object could be designed to interpret messages from both a two button and a three button mouse. In accounting for messages from either of the two I/O devices, the designers could, for example, design the application object so that a message indicating that the third button of the 3-button mouse is depressed is equivalent (that is, achieves the same results) to depressing both buttons of the 2 button mouse simultaneously. Once the application object (or mechanism to generate it) is completed, however, if the designers want the application object to interpret previously unaccounted-for I/O devices such as a four button mouse, portions of the application object (or generating mechanism) may have to be redesigned.
The problem of accounting for new I/O devices is multiplied by the fact that a typical object-oriented environment contains many application objects, and that there may be a considerable amount of redesigning to be done if one or more I/O devices subsequently develop. Thus, it would be desirable to create some scheme which could act as an intermediate between the I/O device and the application objects which would enable a centralized change or addition to be made, if additional I/O devices are implemented, without having to modifying each application object (or mechanism which generates the application object in an object-oriented environment; for example, a word processing program application object can generate a word processing document application object). To minimize the amount of redesigning of the application objects, such a scheme would require that the messages sent to application objects be sent using a uniform protocol, so that designers of the application objects could design all application objects to expect a consistency in the messages received regardless of the type of I/O device used.
In addition to direct interactions with the I/O devices, there are other mechanisms in object-oriented environments which can generate messages which could be equivalent to those generated directly by I/O devices. For example, as indicated above, moving one icon on top of another in an object-oriented environment (that is, an object-object interaction) can cause certain methods of the application objects to be invoked. So that the application objects do not have to be unnecessarily complex, it would be preferable that messages that are sent to the appropriate application object(s) as a result of this interaction are the same message as equivalent messages sent to the application object(s) by an I/O device directly. Otherwise, the application objects would have to be designed to additionally interpret these messages resulting from the object-object interaction individually.
In the situation where one icon is moved on top of another icon as discussed above, the resultant message (that is, the resultant outcome) from this interaction (which is based upon the methods of the application objects which the icons represent) needs to be determined in some way. A conventional technique for making this determination is to use a procedural-based programming environment which can take into account all of the possible combinations of application objects whose representative icons can be dropped on one another.
A problem with the conventional technique, however, is that application objects can be added subsequent to the creation of such a procedurally-based program which were not accounted for by that program. Since the data types of the variables of procedural programs must be known when the program is compiled (that is, the variables are "statically bound"), if variables used to pass a message from one application object to another application object are not of the same type, some data-type conversion must then occur. If the procedural programming environment allows for many different data types, such conversions can become quite cumbersome and complex. What is needed, then, is a system or method for resolving object-object interactions in an environment in which the variables can be "dynamically" bound (that is, bound at run-time), so that data conversions will be unnecessary.
Certain aspects of object-oriented environments which are relevant to the following discussion are noted below. One fundamental aspect of object-oriented environments is that application objects can be organized into classes in a hierarchical fashion. A class defines a certain category or grouping of functions and data within a single entity. Refinement of the methods of the class is achieved by the creation of "sub-classes." In other words, a class can be thought of as a genus, and its subclass as the species. Subclasses allow the introduction of a new class into the class hierarchy, and inherit the behaviors of its superclass while adding new behaviors to the superclass.
Classes are abstract generic descriptions of application objects, methods and behaviors. Instances of a class are created in an object-oriented environment dynamically. An instance is a specific individual entity, something concrete having observable behavior. Instances are dynamically created and deleted. The class, however, is the broad concept under which the instance belongs, and is an abstract concept. The instance inherits all the methods of its class, but has particular individual values associated with it that are unique.
In an object-oriented environment, a class describes certain parameters shared by all instances of the class and certain methods or behaviors. There is only one location in the memory of a computer for the class. There may, however, by numerous instances of the class, each of which has different values and different physical locations in memory.
For example, at the top of an object hierarchy might be an application object called "Office Objects." Methods of Office Objects might include a print method where the user could specify which printer to use by moving the icon of a document to be printed over a printer icon. A class beneath"Office Objects" might be "Word Processors." Methods of application objects in this class might include the ability to send certain control signals to the printers. Beneath this class might be another class such as "Display Write 5". Its methods would be those of that particular word processing program, and would have some formatting information specific to Display Write 5.
In summary, what is needed is an intermediate layer between I/O devices and application objects in an object-oriented environment, such that appropriate messages will be interpreted into a device-independent common protocol, and then be sent to the application objects regardless of the I/O device being used. This would allow for a change to be made in a single location if a new I/O device is to be added. Also, what is needed is a system or method for interactively determining the outcome of an event involving the interaction of two application objects such that the correct message can be sent to the appropriate application object. Such a system or method should use an approach in which the inefficiencies of static binding are overcome.